Depend on plutus-script-utils #1656
Conversation
locallycompact
commented
Sep 26, 2024
locallycompact
commented
- CHANGELOG updated or not needed
- Documentation updated or not needed
- Haddocks updated or not needed
- No new TODOs introduced or explained herafter
| @@ -107,20 +116,21 @@ validator (_party, _commit, headId) r ctx = | |||
| headOutputValue = | |||
| txOutValue . head $ txInfoOutputs (scriptContextTxInfo ctx) | |||
|
|
|||
| compiledValidator :: CompiledCode ValidatorType | |||
| compiledValidator :: TypedValidator CommitValidator | |||
There was a problem hiding this comment.
IIRC this was adding some overhead to the plutus scripts and that's why we ended up with "plain type aliases" on DatumType and RedeemerType.
Might not be the case anymore, but we should be cautious.
| validatorHash :: ScriptHash | ||
| validatorHash = scriptValidatorHash PlutusScriptV2 validatorScript | ||
| validatorHashAddress :: Address | ||
| validatorHashAddress = Ledger.scriptValidatorHashAddress validatorHash' Nothing |
There was a problem hiding this comment.
I think we do not need Address values for our script as we only would need to depend on the script hashes (ValidatorHash now?)
| -- NOTE: Ada in initialValue is usually lower than in the locked ADA due | ||
| -- NOTE: Ada in initialValue is usually lower than in the locked ADA due | ||
| -- to higher deposit needed for commit output than for initial output | ||
| -- to higher deposit needed for commit output than for initial output |
There was a problem hiding this comment.
Something's wrong with your editor or tools here.
There was a problem hiding this comment.
I would suggest not doing this at the same time. Most likely, not using this custom script context will blow up the execution unit cost and makes us unable to merge.
There was a problem hiding this comment.
ScriptContext is everywhere in plutus-script-utils, so we would not be able to drop our functions. Maybe making sure we have the same module interface as plutus-script-utils is a good idea so we can swap one for the other ongoing.
| --sha256: sha256-bhaJsWqjhojpbwxLX1+vVPSPz86tbhDcBUHk6M1HPzU= | ||
| subdir: | ||
| plutus-script-utils | ||
| plutus-ledger |
There was a problem hiding this comment.
Can't we use the packages from CHaP?
There was a problem hiding this comment.
It isn't merged yet because it's a monorepo that would require fixes to cardano-node-enulator as well.
There was a problem hiding this comment.
Have raised IntersectMBO/cardano-node-emulator#38
There was a problem hiding this comment.
Do we need the plutus-ledger entry here? I don't see it used in our cabal files.
There was a problem hiding this comment.
This dependency will not help us much anymore if we switch to aiken. We should close this.
locallycompact
force-pushed
the
plutus-script-utils
branch
2 times, most recently
from
30ec6db
to
6682e79
Compare
locallycompact
changed the title
locallycompact
force-pushed
the
plutus-script-utils
branch
from
6682e79
to
45dc3d1
Compare
Transaction costsSizes and execution budgets for Hydra protocol transactions. Note that unlisted parameters are currently using
Script summary
|
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 5520 | 5.93 | 2.33 | 0.46 |
| 2 | 5719 | 7.40 | 2.92 | 0.48 |
| 3 | 5920 | 8.67 | 3.41 | 0.51 |
| 5 | 6326 | 11.54 | 4.55 | 0.55 |
| 10 | 7330 | 18.43 | 7.28 | 0.67 |
| 55 | 16378 | 80.37 | 31.78 | 1.75 |
Commit transaction costs
This uses ada-only outputs for better comparability.
| UTxO | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 569 | 10.53 | 4.16 | 0.29 |
| 2 | 756 | 13.87 | 5.66 | 0.34 |
| 3 | 947 | 17.34 | 7.21 | 0.38 |
| 5 | 1323 | 24.67 | 10.45 | 0.48 |
| 10 | 2251 | 45.23 | 19.37 | 0.75 |
| 20 | 4124 | 96.00 | 40.77 | 1.40 |
CollectCom transaction costs
| Parties | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|
| 1 | 57 | 564 | 21.48 | 8.43 | 0.41 |
| 2 | 114 | 671 | 33.96 | 13.45 | 0.55 |
| 3 | 170 | 782 | 44.11 | 17.72 | 0.67 |
| 4 | 226 | 893 | 57.95 | 23.48 | 0.83 |
| 5 | 283 | 1004 | 75.14 | 30.58 | 1.02 |
| 6 | 336 | 1116 | 90.69 | 37.23 | 1.20 |
Cost of Decrement Transaction
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 636 | 17.71 | 7.79 | 0.38 |
| 2 | 727 | 17.83 | 8.53 | 0.39 |
| 3 | 862 | 19.11 | 9.75 | 0.41 |
| 5 | 1166 | 22.73 | 12.62 | 0.48 |
| 10 | 2188 | 35.16 | 21.02 | 0.68 |
| 50 | 7713 | 95.17 | 73.76 | 1.79 |
Close transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 644 | 20.09 | 9.02 | 0.41 |
| 2 | 779 | 21.51 | 10.40 | 0.43 |
| 3 | 969 | 23.42 | 12.16 | 0.47 |
| 5 | 1232 | 26.15 | 14.89 | 0.52 |
| 10 | 1955 | 33.99 | 22.29 | 0.67 |
| 50 | 7882 | 96.11 | 81.95 | 1.86 |
Contest transaction costs
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 630 | 25.53 | 10.82 | 0.46 |
| 2 | 866 | 28.08 | 12.99 | 0.51 |
| 3 | 986 | 29.77 | 14.46 | 0.54 |
| 5 | 1260 | 33.30 | 17.48 | 0.60 |
| 10 | 1990 | 42.87 | 25.59 | 0.77 |
| 39 | 6444 | 97.96 | 73.24 | 1.75 |
Abort transaction costs
There is some variation due to the random mixture of initial and already committed outputs.
| Parties | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|
| 1 | 5400 | 17.60 | 7.64 | 0.59 |
| 2 | 5469 | 25.20 | 10.90 | 0.67 |
| 3 | 5773 | 43.91 | 19.51 | 0.90 |
| 4 | 5723 | 49.83 | 21.84 | 0.96 |
| 5 | 5998 | 77.37 | 34.46 | 1.29 |
| 6 | 6164 | 99.03 | 44.22 | 1.54 |
FanOut transaction costs
Involves spending head output and burning head tokens. Uses ada-only UTxO for better comparability.
| Parties | UTxO | UTxO (bytes) | Tx size | % max Mem | % max CPU | Min fee ₳ |
|---|---|---|---|---|---|---|
| 5 | 0 | 0 | 5358 | 7.93 | 3.34 | 0.47 |
| 5 | 1 | 56 | 5391 | 9.14 | 4.09 | 0.49 |
| 5 | 5 | 284 | 5527 | 13.38 | 6.81 | 0.55 |
| 5 | 10 | 570 | 5698 | 19.24 | 10.45 | 0.63 |
| 5 | 20 | 1139 | 6037 | 30.56 | 17.57 | 0.79 |
| 5 | 30 | 1708 | 6378 | 42.08 | 24.77 | 0.95 |
| 5 | 40 | 2278 | 6718 | 53.60 | 31.98 | 1.11 |
| 5 | 50 | 2849 | 7059 | 64.74 | 39.03 | 1.27 |
| 5 | 81 | 4613 | 8110 | 99.51 | 60.99 | 1.75 |
End-to-end benchmark results
This page is intended to collect the latest end-to-end benchmark results produced by Hydra's continuous integration (CI) system from the latest master code.
Please note that these results are approximate as they are currently produced from limited cloud VMs and not controlled hardware. Rather than focusing on the absolute results, the emphasis should be on relative results, such as how the timings for a scenario evolve as the code changes.
Generated at 2024-09-30 11:04:07.475011784 UTC
Baseline Scenario
| Number of nodes | 1 |
|---|---|
| Number of txs | 3000 |
| Avg. Confirmation Time (ms) | 4.190294722 |
| P99 | 8.854895559999928ms |
| P95 | 5.078154199999999ms |
| P50 | 3.9758515ms |
| Number of Invalid txs | 0 |
Three local nodes
| Number of nodes | 3 |
|---|---|
| Number of txs | 9000 |
| Avg. Confirmation Time (ms) | 23.671650100 |
| P99 | 117.88675613000002ms |
| P95 | 30.6773404ms |
| P50 | 20.5037475ms |
| Number of Invalid txs | 0 |
